So this PR fixes the issue by deleting those default rests during the clone process. But I was wondering: maybe those default rests should never have been created, if the first thing that will happen to them is that they are deleted. I suspect they are created when inserting the staff into the score, so before cloneStaff. Maybe you could look into that.

I understand that. I have a question: Would you like this to be for every case where a staff member is cloned AND linked? I think the problem is that the functions being used are also what create default staffs, and I'm unsure how to introduce the condition whether or not to remove rests upon default initialization based on the actual time signature. This is my reasoning behind why I did it the way I did. If you have a better suggestion, I can try to implement it, but I can also try my best to do it on my own. However, I did consider this option from your original suggestion, but I couldn't figure out a way to compartmentalize and keep the two scenarios separate.

Score::undoInsertStaff has a createRests parameter, that controls whether default rests are created. It is true by default. Therefore, NotationParts::insertStaff, which is called via NotationParts::doAppendStaff, will always create rests. I think the solution would be to add a createRests parameter to NotationParts::insertStaff and NotationParts::doAppendStaff, and pass that on to undoInsertStaff. Then in NotationParts::appendLinkedStaff, where doAppendStaff is called, pass false to that parameter.

@skalra4 Something went wrong while rebasing. It looks like you first rebased, then pulled the unrebased version from your fork on GitHub, and then pushed. Instead, you should rebase, and then force-push. So:

git pull --rebase upstream master
git push -f

I apologize for the messy working tree. Git still gets me, especially on big projects with many branches and changes.

No worries. It looks correct now!

Great. Thanks so much for all the help. I appreciate and like the MuseScore dev community a lot!